There has been extensive prior work in the design and implementation of distributed and clustered file systems. For example, the book “Catalogue of Distributed File/Operating Systems”, by Uwe Borghoff, published by Springer-Verlag. 1992, covers thirteen “traditional” distributed file systems, three “object-oriented” distributed file systems, twenty-three “traditional” distributed operating systems (where it is understood that an operating system may contain a file system as a component), eighteen “object-oriented” distributed operating systems, as well as a number of closely related systems and related projects. Among the distributed file systems covered are for example NFS (network file system) and AFS (Andrew file system), later versions of which are still in use at the current time.
Early versions of some distributed file systems did not support concurrent access. For example, there were no mechanisms for locking a file opened for writing by two or more independent applications so as to prevent inconsistent data. A related problem is that of coherency control: if file data is cached, it is necessary in most cases that applications be provided with the most recent version of the data when reading from the file, and this data may reside in the cache of a client machine rather than on the file server. Here, the context implies that the term “cache” is being used to refer to a system software managed cache residing in the main memory of a client machine or file server (as opposed to processor caches for example, which in general are transparent to software and managed by hardware means).
Current distributed file systems generally support both concurrency and coherency control. Typically, files are locked at some granularity, for example at the level of the entire file or at block granularity, and locks are held on data in a client machine's cache as long as the data resides in the cache, even after applications using the data have closed the file. The latter technique has been referred to as lock caching (or lock retention), and is used for coherency control. The technique has been well-known for some time; for example in the context of multi-system data sharing in database systems, in the paper “A Fast General-Purpose Hardware Synchronization Mechanism” by J. T. Robinson, appearing in the Proceedings of the 1985 ACM-SIGMOD International Conference on Management of Data, on page 124 of the conference proceedings the following technique is described: “In order to prevent a data object that is in the cache of processor P1 being invalidated due to an update made to the object on processor P2, it may be desired to have the local concurrency control of P1 continue to hold a lock on the object as long as it is in the cache, even after all local transactions accessing the object have completed” (where again “cache” in this context refers to a software managed cache residing in main memory). In order to release a cached lock held on modified data, the data must be written to the file server prior to releasing the lock, in order to ensure that the most recent version of the modified data is available to other client machines.
Potential performance problems resulting from lock caching, and from caching modified data that may be required by applications running on other client machines, have been recognized in the prior art. For example, in “Data Lock Management in a Distributed File Server System Determines Variable Lock Lifetime in Response to Request to Access Data Object”. U.S. Pat. No. 5,615,373, 1993, mechanisms are described in which locks are held for variable periods of time. This can be thought of as lock caching in which, however, cached locks are automatically released after a specified interval (where the interval may be determined, for example, by measured read/write ratios for files). However, a number of important problems remain.
Some of these problems are as follows. Typically, the usage patterns of certain file types, or certain files as used by given applications, are known in advance. A simple example is that program files (that is executable files) and small documentation files are typically accessed in read-only mode at file granularity by every client machine. A second example is a system status file that is periodically updated by every client machine in the system: for such files it would be desirable not to cache locks, and to write through changes to the file on each update (as opposed to leaving the updated version in a client machine's cache, and only writing through changes on a lock conflict caused by the file being opened on another client machine). A third example is as follows: even though a certain file may be known to be highly shared in read/write mode, it may also be known that the usage pattern of the file is such that it is relatively infrequently accessed, and typically accessed by a different client machine on each subsequent access. In such a case it would be desirable to lock at file granularity, not to cache locks, and to write-through changes.
Another problem is granularity of locking: certain file types, or certain files used by given applications, are known in advance to be accessed at the file level (the entire file is opened, read, and possibly written) or at the block level (individual blocks within the file are read and possibly written, as in for example files implementing certain types of indexes).
Yet another problem is guaranteeing a level of service (for example, response time) for given applications and associated file types. For example, in the case of files used by an OLTP (online transaction processing) application, it may be desirable to lock at the block level, not to cache locks, and to write-through changes to files at the completion of each update. In the case of this particular example, such a policy is designed to optimize performance and minimize the response time for each client machine running the OLTP application (since it is known in advance that certain files used by the OLTP application are highly shared among multiple client machines in read/write mode at block granularity). There are many other examples in which a system administrator may wish to specify, for example, the granularity of locking, whether locks are cached, and whether modified data is written-through to a shared file server (or in the case of a storage area network, to a shared device), for a given application program and associated file types with known usage patterns, in order to optimize performance and provide varying levels of service.